1.3.3 '거의 맞는(Mostly Correct)' 코드의 위험성: 99%의 정확도가 엔터프라이즈 환경에서 실패하는 이유

1.3.3 ‘거의 맞는(Mostly Correct)’ 코드의 위험성: 99%의 정확도가 엔터프라이즈 환경에서 실패하는 이유

1. 확률적 생성의 기만과 소프트웨어 공학의 위기

현대 소프트웨어 공학은 거대 언어 모델(LLM)의 등장으로 인해 유례없는 생산성 혁신과 동시에 근본적인 신뢰성의 위기에 직면해 있다. 인공지능이 생성하는 코드는 전통적인 프로그래밍의 산물인 결정론적(Deterministic) 논리 체계가 아니라, 훈련 데이터의 통계적 분포에 기반하여 다음 토큰을 예측하는 확률적(Probabilistic) 추론의 결과물이다. 이러한 패러다임의 전환은 ‘거의 맞는(Mostly Correct)’ 코드라는 새로운 범주의 결함을 양산하며, 이는 특히 무결성과 안정성을 최우선으로 하는 엔터프라이즈 환경에서 시한폭탄과 같은 위협으로 작용한다. 99%의 정확도는 소비자용 애플리케이션이나 개인 프로젝트에서는 마법 같은 성취로 느껴질 수 있으나, 수백만 건의 트랜잭션을 처리하는 기업형 시스템에서는 매일 수천 건의 오류를 발생시키는 불합격 지표에 불과하다.

엔터프라이즈 소프트웨어는 본질적으로 정밀함(Precision)과 책임성(Accountability)을 요구한다. 비즈니스 로직은 0과 1 사이의 모호한 경계를 허용하지 않으며, 단 한 번의 예외가 전체 금융 시스템의 무결성을 훼손하거나 규제 준수(Compliance) 위반으로 이어질 수 있다. 인공지능이 제공하는 ‘거의 맞는’ 코드는 외형적으로는 완벽한 문법과 구조를 갖추고 있어 개발자의 경계심을 무너뜨리지만, 그 내부에는 비결정성(Nondeterminism)에서 기인한 미세한 논리적 결함이 숨어 있다. 이러한 ’신뢰의 착시’는 검증되지 않은 코드가 운영 환경으로 유입되는 경로를 제공하며, 결과적으로 기업의 기술 부채와 운영 리스크를 기하급수적으로 증폭시킨다.

2. 벤치마크의 함정과 실제 정확도의 괴리

현재 인공지능 모델의 코드 생성 능력을 평가하는 표준 벤치마크인 HumanEval이나 MBPP는 인공지능의 실무 능력을 과장하는 경향이 있다. “Is Your Code Generated by ChatGPT Really Correct? Rigorous Evaluation of Large Language Models for Code Generation” 논문에 따르면, 기존 벤치마크는 매우 단순한 단위 테스트(Unit Test)에 의존하고 있어 모델의 잠재적 오류를 포착하는 데 한계가 있다. 연구진이 제안한 EvalPlus 프레임워크를 통해 테스트 케이스를 81배 확장하여 재평가했을 때, 모델들의 pass@k 지표는 평균 15.1%에서 최대 28.9%까지 하락하는 결과를 보였다. 이는 인공지능이 생성한 코드가 ‘겉으로만 맞을 뿐’ 실제로는 수많은 코너 케이스(Corner Case)에서 실패하고 있음을 실증한다.

예를 들어, 두 리스트에서 공통 요소를 추출하여 정렬된 상태로 반환하는 함수를 생성할 때, 인공지능은 종종 중간 단계에서 리스트를 세트(Set)로 변환하여 중복을 제거한다. 이 과정에서 세트의 비결정적 특성으로 인해 정렬 순서가 파괴될 수 있음에도 불구하고, 단순한 테스트 케이스는 이를 잡아내지 못한다. 이러한 논리적 결함은 데이터의 순서가 중요한 엔터프라이즈 환경에서 심각한 데이터 정합성 문제를 야기한다. “BenchFrame” 프레임워크를 적용한 HumanEvalNext 연구에서도 최신 모델들의 정확도가 기존 대비 31.2%나 감소하는 양상을 보였으며, 이는 우리가 ’성능’이라고 믿었던 수치가 사실은 불충분한 검증의 산물임을 시사한다.

3. 지수적 붕괴: 복합 오류 문제(The Compound Error Problem)의 수학적 분석

엔터프라이즈 워크플로우는 단일 함수가 아니라 수많은 논리적 단계의 연쇄로 구성된다. 여기서 ’99%의 정확도’가 가진 치명적인 약점이 드러난다. 개별 단계의 오류율이 낮더라도 단계가 누적될수록 전체 시스템의 성공 확률은 지수적으로 급감하는 ’복합 오류 문제(The Compound Error Problem)’가 발생하기 때문이다. “The Six Sigma Agent: Achieving Enterprise-Grade Reliability in LLM Systems Through Consensus-Driven Decomposed Execution” 논문은 이 현상을 수학적으로 증명한다.

워크플로우가 m개의 독립적인 단계로 이루어져 있고, 각 단계의 성공 확률을 a라고 할 때, 전체 프로세스의 최종 성공 확률 P(success)는 다음과 같다.

P(success) = a^m

이 수식을 바탕으로 정확도 a가 99%와 99.9%일 때 단계 수 m의 증가에 따른 성공 확률 변화를 분석하면 아래와 같은 파멸적인 결과를 확인할 수 있다.

단계 누적에 따른 최종 성공 확률의 지수적 감소

단계 수 (m)99% 정확도 (a=0.99)99.9% 정확도 (a=0.999)비고 \vert
199.0%99.9%개별 함수 수준 \vert
1090.4%99.0%단순 모듈 결합 \vert
5060.5%95.1%비즈니스 프로세스 \vert
10036.6%90.5%엔터프라이즈 워크플로우 \vert
10000.004%36.8%시스템 전체 통합 \vert

위 지표에서 알 수 있듯이, 100개 이상의 단계가 얽힌 복잡한 기업용 시스템에서 99%의 정확도를 가진 에이전트를 사용하는 것은 사실상 시스템 작동을 포기하는 것과 같다. 36.6%의 성공 확률은 3번 중 2번은 오류가 발생한다는 의미이며, 이는 수동 복구 비용이 자동화로 인한 이득을 압도하게 만든다. 엔터프라이즈에서 요구하는 ‘식스 시그마(Six Sigma)’ 수준, 즉 100만 번의 기회 중 3.4회 미만의 결함(3.4 DPMO)을 달성하기 위해서는 99%의 정확도를 넘어선 완전히 새로운 신뢰성 공학적 접근이 필요하다.

공학적 생산성 역설(Engineering Productivity Paradox)과 기술 부채

인공지능을 통한 코드 생성 속도의 비약적인 향상은 역설적으로 시스템 전체의 품질 저하와 관리 비용의 상승을 초래한다. 이를 ’공학적 생산성 역설(Engineering Productivity Paradox)’이라 정의한다. 인공지능은 개발자가 수동으로 코딩할 때보다 2배 이상 빠르게 코드를 쏟아내지만, 그 결과물은 전역적 아키텍처(Global Architecture)에 대한 고려가 없는 ’국소적 최적화(Local Optimization)’에 치중되어 있다.

이로 인해 발생하는 구체적인 기술 부채의 메커니즘은 다음과 같다.

첫째, 구조적 붕괴와 중복의 증가다. LLM은 기존 코드베이스의 복잡한 의존성 체계나 설계 원칙을 완벽히 이해하지 못한 채 가장 확률 높은 코드를 생성한다. 2024년의 통계에 따르면, 인공지능 도입 이후 5라인 이상의 중복 코드 블록이 8배나 증가했으며, 복잡도를 측정하는 사이클로매틱 복잡도(Cyclomatic Complexity)와 할스테드 메트릭(Halstead Metrics) 또한 인공지능 생성 코드에서 유의미하게 높게 나타났다. 이는 시스템의 유지보수 난이도를 지수적으로 높인다.

둘째, 리뷰 병목 현상이다. 생성되는 코드의 양이 방대해지면서 인간 개발자의 코드 리뷰 부담은 91% 이상 증가했으며, PR(Pull Request)의 크기 또한 154% 가량 커졌다. 개발자의 67%는 인공지능이 생성한 코드를 디버깅하는 데 더 많은 시간을 소요하고 있다고 보고했다. 즉, 작성 속도는 빨라졌으나 ’라스트 마일(Last Mile)’에서의 검증 비용이 전체 생산성을 갉아먹고 있는 것이다.

셋째, 잠재적 결함 밀도의 상승이다. 인공지능 생성 코드는 인간이 작성한 코드보다 논리 오류 및 정확성 문제가 75% 더 빈번하게 발생하며, 특히 예외 처리(Error Handling)나 가독성 면에서는 3배 이상의 품질 저하를 보였다. 이러한 ‘거의 맞는’ 코드는 당장은 작동하는 것처럼 보이지만, 특정 조건이 갖춰졌을 때 예기치 못한 실패를 유도하는 잠재적 결함으로 축적된다.

도리 효과(Dory Effect)와 맥락 상실의 리스크

엔터프라이즈 시스템의 코드는 수십 년에 걸친 비즈니스 지식과 아키텍처의 진화가 응축된 유기체와 같다. 그러나 현재의 인공지능 모델들은 제한된 컨텍스트 윈도우(Context Window)로 인해 시스템 전체의 거시적 맥락을 유지하지 못하는 ’도리 효과(Dory Effect)’를 겪는다. 이는 영화 속 단기 기억 상실증을 앓는 캐릭터 ’도리’처럼, 모델이 과거의 설계 결정이나 이전에 해결된 버그의 이력을 망각하고 동일한 실수를 반복하는 현상을 의미한다.

도리 효과로 인한 위험은 특히 대규모 시스템 통합 단계에서 극대화된다. 인공지능은 특정 함수 내부의 로직을 ‘거의 맞게’ 작성할 수 있지만, 그 함수가 호출하는 다른 모듈의 부수 효과(Side Effect)나 전역 상태(Global State)에 미치는 영향까지는 계산하지 못한다. “The Hidden Cost of AI Coding” 보고서에 따르면, 이러한 맥락 결여는 시스템의 구조적 부패를 가속화하며, 결국 개발자가 인공지능의 코드를 이해하지 못한 채 ’블랙박스’처럼 다루게 만들어 팀 내 지식 전수와 온보딩을 방해하는 요소가 된다.

보안의 비대칭성: 99%의 방패를 뚫는 1%의 송곳

보안 영역에서 ‘거의 맞는’ 코드는 치명적인 재앙의 서곡이다. 인공지능은 통계적으로 가장 흔한 코드 패턴을 따르기 때문에, 보안적으로 취약한 레거시 패턴이나 안티 패턴(Anti-pattern)까지도 충실히 복제한다. “Evaluating and Mitigating the Growing Risk of LLM-Discovered 0-Days” 보고서에 따르면, 인공지능 생성 코드의 보안 취약점 발생률은 인간 대비 최대 2.74배 높으며, 약 45%의 코드가 최소 하나 이상의 보안 결함을 포함하고 있다.

인공지능이 양산하는 주요 보안 위협은 다음과 같은 네 가지 범주로 구분된다.

인공지능 생성 코드의 주요 보안 결함 유형

결함 유형발생 원인 및 매커니즘엔터프라이즈 영향 \vert
하드코딩된 자격 증명인증 로직 생성 시 관습적으로 API 키나 패스워드를 코드에 포함외부 유출 시 시스템 전면 통제권 상실 \vert
패키지 환각 (Hallucination)존재하지 않지만 그럴듯한 이름의 라이브러리 의존성 제안공격자가 해당 이름으로 악성 패키지 등록 시 공급망 공격 성공 \vert
취약한 인증 흐름겉보기에는 완벽하지만 세션 관리나 권한 확인 단계가 누락됨미인증 사용자의 관리자 권한 획득 및 데이터 탈취 \vert
방어적 코드 누락입력값 검증, 경계값 체크, 오버플로우 방지 로직을 ’생략’함SQL 인젝션, 버퍼 오버플로우 등 전통적 공격에 무방비 \vert

특히 위험한 지점은 인공지능이 보안 공격자로 활용될 때의 비대칭성이다. Anthropic의 연구에 따르면 최신 모델인 Opus 4.6은 별도의 도구 없이도 수백 개의 제로데이(0-Day) 취약점을 스스로 찾아내고 검증할 수 있는 능력을 갖췄다. 공격자는 인공지능을 통해 단 몇 달러의 비용으로 대규모 보안 함정을 파는 반면, 방어자는 인공지능이 생성한 ‘거의 맞는’ 코드 속에 숨겨진 미세한 취약점 1%를 찾기 위해 엄청난 자원을 투입해야 한다. 99%의 보안 정확도는 1%의 파멸을 막지 못하며, 이는 인공지능 생성 코드를 무비판적으로 수용하는 엔터프라이즈가 직면한 가장 가혹한 현실이다.

라스트 마일(Last Mile) 문제: 정책과 거버넌스의 부재

소프트웨어를 완성하는 것과 배포하는 것 사이에는 거대한 간극이 존재하며, 이를 ’라스트 마일(Last Mile)’이라 부른다. 인공지능은 구문(Syntax)적으로 완벽하고 테스트를 통과하는 코드를 작성할 수 있지만, 해당 코드가 조직의 내부 정책(Policy), 법적 규제, 라이선스 요건에 부합하는지 판단할 능력이 없다. “AI Can Write Code, But Only Policy Can Ship It“에서 Brian Fox는 소프트웨어 배포는 ’구문의 문제’가 아니라 ’정책의 문제’라고 단언한다.

엔터프라이즈 환경에서의 라스트 마일 병목 현상은 다음과 같은 양상으로 나타난다.

첫째, 무형의 정책과 인공지능의 충돌이다. 대기업의 보안 규정이나 코딩 표준은 흔히 슬랙 스레드, 문서, 혹은 고참 개발자의 머릿속에 ’파편화’되어 존재한다. 인공지능은 이러한 비정형적 정책을 직관할 수 없으므로, 생성된 코드의 99%가 기능적으로 우수하더라도 1%의 정책 위반으로 인해 배포가 불가능한 상황이 반복된다.

둘째, 신뢰의 트랩(Trust Trap)이다. 모델의 성능이 향상될수록 개발자는 인공지능의 결과물을 맹신하게 되며, 이는 결과적으로 ’정밀한 검토’를 건너뛰게 만드는 심리적 기제로 작용한다. “Most Devs Use AI-Generated Code They Don’t Understand” 보고서는 개발자들이 자신이 완전히 이해하지 못한 인공지능 코드를 서비스에 투입하고 있으며, 이로 인해 시스템의 불투명성과 책임 소재의 불분명함이 가중되고 있음을 경고한다.

셋째, 경제적 타당성의 결여다. Brookings 연구소의 AI-Labor Cost Framework에 따르면, 인공지능 도입을 위해 필요한 ‘라스트 마일 커스터마이징’ 비용이 인건비 절감액을 상회하는 경우가 빈번하다. 특히 금융이나 의료처럼 100%의 정확도가 요구되는 분야에서는 ‘거의 맞는’ 코드를 수정하고 보완하는 비용이 처음부터 다시 짜는 비용보다 커지는 ‘마이너스 생산성’ 구간에 진입하게 된다.

비결정성의 비즈니스 위협: 실제 실패 사례 분석

‘거의 맞는’ 코드가 엔터프라이즈의 비즈니스 무결성을 어떻게 파괴하는지 실제 시나리오를 통해 고찰한다.

사례 1: 금융 데이터의 논리적 표류 (Logic Drift)

인보이스에서 데이터를 추출하는 자동화 시스템에 LLM을 투입했을 때, 동일한 PDF 파일에 대해 실행 시마다 결과값이 달라지는 현상이 발견되었다. 한 번은 $50,000의 매출을 정확히 뽑아내지만, 다음 실행에서는 숫자를 오인하거나 합계 계산에서 미세한 오차를 발생시킨다. 이러한 비결정적 출력은 회계 감사와 세무 보고에서 심각한 결함으로 간주되며, “Good Enough“라는 논리가 비즈니스 크리티컬 영역에서는 통용될 수 없음을 보여준다.

사례 2: 제약 분야의 안전 가드레일 환각

약물 상호작용을 체크하는 에이전트가 “A약과 B약을 혼용해도 되는가?“라는 질문에 99번은 “위험하다“고 답하다가, 단 1번 확률적 편향으로 인해 “안전하다“고 응답한다고 가정하자. 이러한 오류는 단순한 ’버그’가 아니라 인명 사고와 직결되는 재난이다. 구글의 Gemini Neuro-Symbolic 연구팀은 이러한 확률적 위험을 차단하기 위해 모델의 답변을 강제로 그래프 데이터베이스(Spanner Graph)의 규칙과 대조하는 엄격한 결정론적 계층을 추가해야 한다고 강조한다.

사례 3: 클라우드 인프라의 권한 과잉 (Over-privileged Credentials)

인공지능이 생성한 인프라 구성 코드(IaC)가 편의성을 위해 S3 버킷 권한을 ’Public Read’로 설정하거나, IAM 역할을 과도하게 넓게 설정하는 경우가 빈번하다. 이는 기능적으로는 배포에 성공(Success)한 것으로 보이지만, 기업 보안 관점에서는 즉각적인 침해 사고의 원인이 된다. 99%의 배포 성공률 뒤에 숨겨진 1%의 권한 설정 오류가 기업 전체의 데이터를 노출시키는 결과를 낳는다.

결론: 99%를 넘어서는 확정적 오라클의 필요성

‘거의 맞는’ 코드는 인공지능 기반 소프트웨어 개발의 가장 위험한 함정이다. 그것은 개발자에게는 생산성의 환상을, 경영진에게는 비용 절감의 착시를 제공하지만, 그 대가로 시스템의 근간인 결정론적 신뢰성을 훼손한다. 엔터프라이즈 환경에서 99%의 정확도는 축복이 아니라 관리되지 않는 1%의 위험을 의미하며, 이는 지수적 오류 누적을 통해 시스템 전체의 붕괴로 이어진다.

우리가 도달해야 할 지점은 인공지능의 확률적 출력을 무조건적으로 수용하는 것이 아니라, 이를 엄격하게 검증하고 통제할 수 있는 ‘결정론적 정답지(Deterministic Ground Truth)’, 즉 오라클(Oracle) 시스템을 구축하는 것이다. 인공지능을 창의적인 제안자로 활용하되, 최종적인 집행과 검증은 식스 시그마 에이전트와 같은 다수결 합의 구조나 신경 기호적 레이어를 통해 이루어져야 한다. 99%의 모호한 정확도를 100%의 확정적 안정성으로 변환하는 공학적 안전장치가 마련되지 않는다면, 인공지능은 엔터프라이즈의 파트너가 아닌 거대한 기술 부채의 발원지로 남게 될 것이다.

결국 인공지능 소프트웨어 개발의 성패는 모델이 얼마나 ’똑똑한가’가 아니라, 우리가 그 모델의 ’부정확함’을 얼마나 체계적으로 통제하고 관리할 수 있는가에 달려 있다. ‘거의 맞는’ 것만으로는 부족하며, 엔터프라이즈는 오직 ‘확실히 맞는’ 것만을 허용해야 한다. 이것이 확률의 시대를 지나 진정한 인공지능 공학의 시대로 나아가기 위한 첫 번째 원칙이다.

참고 자료

  1. Beyond RAG: Solving “Compliance Hallucinations” with Gemini & Neuro-Symbolic AI | by Sadanandl | Google Cloud - Medium, 2월 15, 2026에 액세스, https://medium.com/google-cloud/beyond-rag-solving-compliance-hallucinations-with-gemini-neuro-symbolic-ai-b48fcd2f431f
  2. The Six Sigma Agent: Achieving Enterprise-Grade Reliability in LLM Systems Through Consensus-Driven Decomposed Execution - arXiv, 2월 15, 2026에 액세스, https://arxiv.org/html/2601.22290v1
  3. Who Wins as Enterprises Scale AI? Why Incumbents Lead - Vista Equity Partners, 2월 15, 2026에 액세스, https://www.vistaequitypartners.com/insights/who-wins-as-enterprises-scale-ai/
  4. Why LLMs will inevitably fail in enterprise environments : r/BetterOffline - Reddit, 2월 15, 2026에 액세스, https://www.reddit.com/r/BetterOffline/comments/1p1pk0v/why_llms_will_inevitably_fail_in_enterprise/
  5. The Death of the Generalist: 5 Specialised Copilots Rewriting the Enterprise Stack, 2월 15, 2026에 액세스, https://aidatainsider.com/ai/5-specialised-copilots-outperforming-generic-ai/
  6. AI vs human code gen report: AI code creates 1.7x more issues, 2월 15, 2026에 액세스, https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
  7. The inevitable rise of poor code quality in AI-accelerated codebases …, 2월 15, 2026에 액세스, https://www.sonarsource.com/blog/the-inevitable-rise-of-poor-code-quality-in-ai-accelerated-codebases/
  8. Is Your Code Generated by ChatGPT Really … - Lingming Zhang, 2월 15, 2026에 액세스, https://lingming.cs.illinois.edu/publications/neurips2023.pdf
  9. Is Your Code Generated by ChatGPT Really Correct? Rigorous Evaluation of Large Language Models for Code Generation - NeurIPS, 2월 15, 2026에 액세스, https://proceedings.neurips.cc/paper_files/paper/2023/file/43e9d647ccd3e4b7b5baab53f0368686-Paper-Conference.pdf
  10. Benchmarking AI Models in Software Engineering: A Review, Search Tool, and Enhancement Protocol - arXiv, 2월 15, 2026에 액세스, https://arxiv.org/html/2503.05860v1
  11. Is Your Code Generated by ChatGPT Really Correct? Rigorous Evaluation of Large Language Models for Code Generation - ResearchGate, 2월 15, 2026에 액세스, https://www.researchgate.net/publication/370469406_Is_Your_Code_Generated_by_ChatGPT_Really_Correct_Rigorous_Evaluation_of_Large_Language_Models_for_Code_Generation
  12. The Six Sigma Agent: Achieving Enterprise-Grade Reliability in LLM Systems Through Consensus-Driven Decomposed Execution - arXiv, 2월 15, 2026에 액세스, https://arxiv.org/html/2601.22290
  13. The Six Sigma Agent: Achieving Enterprise-Grade Reliability in LLM Systems Through Consensus-Driven Decomposed Execution - arXiv, 2월 15, 2026에 액세스, https://www.arxiv.org/pdf/2601.22290
  14. Why AI-Generated Code Costs More to Maintain Than Human-Written Code | by AlterSquare, 2월 15, 2026에 액세스, https://altersquare.medium.com/why-ai-generated-code-costs-more-to-maintain-than-human-written-code-91b57256bd6a
  15. The Last Mile Problem: AI Can Write Code, But Only Policy Can Ship It, 2월 15, 2026에 액세스, https://www.sonatype.com/blog/the-last-mile-problem-ai-can-write-code-but-only-policy-can-ship-it
  16. Why AI-Generated Code Fails in Production: Challenges & Solutions, 2월 15, 2026에 액세스, https://talent500.com/blog/ai-code-production-challenges-solutions/
  17. Blind Trust in AI: Most Devs Use AI-Generated Code They Don’t Understand | Clutch.co, 2월 15, 2026에 액세스, https://clutch.co/resources/devs-use-ai-generated-code-they-dont-understand
  18. LLMs + Security = Trouble - arXiv, 2월 15, 2026에 액세스, https://arxiv.org/html/2602.08422v1
  19. Evaluating and mitigating the growing risk of LLM-discovered 0-days - Anthropic Red Team, 2월 15, 2026에 액세스, https://red.anthropic.com/2026/zero-days/
  20. Issue #19 - Appsec Weekly 🛡️ - Feb 9, 2026, 2월 15, 2026에 액세스, https://appsecweekly.net/p/issue-19-appsec-weekly-feb-9-2026
  21. [tl;dr sec] #315 - Securing OpenClaw, Top 10 Web Hacking Techniques of 2025, Discovering Negative-Days with LLMs, 2월 15, 2026에 액세스, https://tldrsec.com/p/tldr-sec-315
  22. AI-generated code is now the cause of one-in-five breaches – but developers and security leaders alike are convinced the technology will come good eventually - ITPro, 2월 15, 2026에 액세스, https://www.itpro.com/software/development/ai-generated-code-is-now-the-cause-of-one-in-five-breaches-but-developers-and-security-leaders-alike-are-convinced-the-technology-will-come-good-eventually
  23. The AI Last Mile Problem - Brewster Consulting Group, 2월 15, 2026에 액세스, https://www.brewsterconsulting.io/the-ai-last-mile-problem
  24. The last mile problem in AI - Brookings Institution, 2월 15, 2026에 액세스, https://www.brookings.edu/articles/the-last-mile-problem-in-ai/
  25. Why GenAI Fails in Production (and the 5-Levels or Phases with 6-Layers Safety Architecture to Fix It) - Abhishek Jain, 2월 15, 2026에 액세스, https://vardhmanandroid2015.medium.com/why-genai-fails-in-production-and-the-5-levels-or-phases-with-6-layers-safety-architecture-to-fix-27b673dfa55a